<h1 id="the-better-grep-search">the-better-grep-search</h1>
<h2 id="whats-the-problem">What’s the problem?</h2>
<p>For us who do a lot of stuff in command line, we often do text search via <code>grep</code>. I really like <code>grep</code>. But the problem is that these tools were designed in the last century and there are certain aspects of them that make us frown our eyebrows:</p>
<ul>
<li>They have crazy amount of configurations, just do <code>man grep</code> and see for yourself</li>
<li>They default to search for everything, meaning they search built/minified code, library code, svg etc., and you have to manually exclude files types/file paths every time</li>
<li>The output is not very IDE friendly, as a vim user, it’s hard for me to step in and press a few keys and just open that file in vim. I assume for other IDEs the frustration remains</li>
</ul>
<h2 id="why-not-use-ack">Why not use ack?</h2>
<p>Now I understand <code>ack</code> is better, other than the IDE friendliness aspect, <code>ack</code> overcomes all the shortcomings of <code>grep</code> I mentioned above, but hey it’s hackathon, let’s write our new tool!</p>
<h2 id="whats-been-done">What’s been done?</h2>
<p>I have written a script called <code>cs</code> (short for content-search) myself and I have been using it for 3-4 years. I add a few things here and there as I see fit, but I always wanted it to do more. Anyway, here is where I am currently.</p>
<ul>
<li>It automatically ignore files in <code>node-modules/**/*</code> and <code>.git/**/*</code>:</li>
<li>It can show context (a few lines above/below), like this:<br />
<img src="./show-around.png" /></li>
<li>It defaults to ignore super long lines, but this feature can be flagged off, like this:<br />
<img src="./show-long.png" /></li>
<li>It can grab the search output to a scratch vim buffer, where I can do normal vim stuff (including, very usefully, press <code>gf</code> to open that file right away), like this:<br />
<img src="./vim-inspect.gif" /></li>
</ul>
